Every user of our messenger will run and interact with the JAM client. It is a completely separate program from the server, the server will be running on a designated machine and the clients connect to this.

The client architecture used in our project to separate the client into different collaborating parts was the model-view-controller architecture (MVC). MVC is a means of modelling computer systems that splits the design into Model, View and Controller, separating the concerns between them. The model keeps track of the data stored in the system, responds to requests for information and its state from the view, and responds to instructions to change state from the controller. The view renders the model into a user interface for the user to interact with. Multiple views can exist for a single model for different purposes. The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a view port to perform actions based on that input.

This architecture was chosen as it allowed different team members to take responsibility for individual parts of the system. This allowed the implementation process to be split up, with one person building the controller and model, and two implementing the view. All components were developed at the same time and constant co-operation was required to ensure they matched up. It also makes maintaining JAM easier as different views can be swapped in or more protocol messages can be added without too much hassle. 

In our original designs the controller would receive messages from the server and process them instantly. However, as the Java Swing code used to render the graphical user interface will block this listening code, it is possible that incoming messages will be missed. To get around this problem the controller needs to be multi-threaded. A suitable design would be to have the main thread dealing exclusively with reading in messages from the server and writing the message to a queue. Another thread can then constantly be checking for a message in the queue, then when it finds one take it off the queue and process it. Processing the message would involve parsing it then potentially changing the client model and user interface.

We applied this to our system to create the client architecture shown in figure 5.1.
\begin{figure}[ht!]

\centering	

	\includegraphics[scale=0.50]{images/CA_mvc.png}
    \caption{Client MVC architecture}
    \end{figure}
\begin{itemize}
	\item \textbf{Model}
	When designing the model we had to specify everything we needed to store about the state of the client. This was greatly influenced by what was specified as the requirements of the system and by what information the view needed to render the interface.

	The concept of users in the system was a 'must have’ requirement, so the model stores information on the currently logged in user to meet this requirement. Much of the 'should have' functionality is also covered by storing the current users information, such as the ability to set a nickname and an availability. Having a contact list associated with each user was another ‘should have’ feature. To cater for this, the model required a data structure to store the current users contact list.

	To display the user interface, the view regularly required the status of the current user. For example the users nickname and availability appear in multiple different places. As well as user information, a collection of channels currently open is also stored. This helps the view display messages in the correct channel.

	\item \textbf{View}
	This is the graphical user interface that the user interacts with. From our initial interface designs, described in section 5.3, we concluded that private one to one chats and group chats would be dealt with in the same way. Both types would be treated as a channel, and anyone in the channel would receive messages and status updates from people in that channel. This simplified how the view would interact with the rest of the system. The view included many methods such as \texttt{createMainWindow(User user)} and \newline\texttt{paintContactList(ArrayList<User> contacts)}, view methods would be called by the controller when updates to the graphical user interface were required.

	\item \textbf{Network Controller}
	This component extends the MVC architecture to deal with networking code. It listens for messages from the server and passes them to a queue to be dealt with by the process controller. As explained earlier this is to prevent Java Swing code blocking any networking code, so this design keeps them in separate threads.

	\item \textbf{Processing Controller}
	This controller interprets the messages on the queue and communicates and updates that need to be made to the model and view. The view and model talk through the controller so any updates from each component are also sent to the controller and passed on if necessary. The controller abstracts away the syntax of the protocol from the view and model. Once the messages are parsed the other components only need to know about any interface or state changes to be made. 
\end{itemize}
	Each type of message has a different impact on the model or view so although they are all parsed similarly they each require their own method to be processed. On the client side, incoming messages can be grouped into two types. Responses from the server based on messages originally sent by that client, ‘Server Responses’, and messages sent from the server without prompt, ‘Server Actions’. Messages were designed so that each of these would extend a very simple abstract class, ‘Message’. Then specific incoming messages would extend upon either of these. For example, as shown in Figure 5.2, the \texttt{ResponseLogin} class that deals with the servers response to a login action extends \texttt{ServerResponse}. And for when a client receives a message from another user, the class \texttt{ServerActionMessage} extends \texttt{ServerAction}. This design would allow similar messages to be grouped together which makes the code easier to understand and maintain.
